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Integrated Lunar Informa- 
tion Architecture for Deci- 
sion Support Version 3.0 
(ILIADS 3.0) 

ILIADS 3.0 provides the data manage- 
ment capabilities to access CxP-vetted 
lunar data sets from the LMMP-provided 
Data Portal and the LMMP-provided On- 
Moon lunar data product server. (LMMP 
stands for Lunar Mapping and Modeling 
Project.) It also provides specific quanti- 
tative analysis functions to meet the 
stated LMMP Level 3 functional and per- 
formance requirements specifications 
that were approved by the CxP. 

ILIADS 3.0 is a rich client (aka, thick 
client) lunar Geospatial Information 
System (GIS) software application. It is a 
redesigned software framework and ar- 
chitecture that leverages GSFCs experi- 
ence developing the ILIADS 2.0 core 
software. Specifically, ILIADS 3.0 is built 
upon ILIADS 2.0. 

The purpose of ILIADS 3.0 is to pro- 
vide an integrated, rich client lunar 
GIS software application. Most signifi- 
cantly, the objective in designing and 
developing ILIADS 3.0 was to provide a 
flexible and expandable software 
framework that readily enabled new 
features and functions to be integrated 
into ILIADS driven by the science and 
engineering user community. To con- 
tribute to the decision support process, 
ILIADS 3.0 also provides interfaces to 
readily enable interoperability between 
ILIADS 3.0 and other NASA-developed 
lunar information systems whenever it 
may become required to interface ILI- 
ADS with such systems. 

By building upon Goddard’s IRC core 
framework, ILIADS is also well suited to 
being readily integrated with future 
lunar surface system assets (e.g., crewed 
rovers, spacesuits) as an embedded sys- 
tem application. ILIADS 3.0 provides 
cross-platform support and thus exe- 
cutes on a diverse suite of computing 
platforms that are used by NASA scien- 
tists and engineers. The application is 
designed to provide authorized/ 
authenticated users with the ability to 
use the Internet to securely, yet easily, 
identify and locate geographically dis- 
tributed sources of vetted lunar data 
products that have been derived from 
US and international lunar spacecraft 
missions. It can query the data catalogs 


of these sources to identify available 
lunar data products and the metadata 
associated with them. The software uses 
standard OGC (Open Geospatial Con- 
sortium) WMS, WCS, and WFS (Web 
Map Service, Web Coverage Service, 
and Web Feature Service) services to ac- 
cess mapped lunar delta products from 
these sources so that they may be 
processed by ILIADS 3.0 and rendered 
as multiple semi-transparent raster or 
vector visualizations, so that the lunar 
data product information is readily un- 
derstood in the context of one another. 

This work was done by Stephen Talabac, 
Troy Ames, Karin Blank, Carl Hostetter, and 
Matthew Brandt of Goddard Space Flight 
Center. Further information is contained in a 
TSP ( see page 1 ). GSC-1 6210-1 


Relay Forward-Link File 
Management Services 
(MaROS Phase 2) 

This software provides the service- 
level functionality to manage the deliv- 
ery of files from a lander mission repos- 
itory to an orbiter mission repository 
for eventual spacelink relay by the or- 
biter asset on a specific communica- 
tions pass. It provides further functions 
to deliver and track a set of mission-de- 
fined messages detailing lander author- 
ization instructions and orbiter data de- 
livery state. All of the information 
concerning these transactions is per- 
sisted in a database providing a high 
level of accountability of the forward- 
link relay process. 

This is an improvement over legacy 
processes that required lander client 
users to log into orbiter mission worksta- 
tions and run orbiter-specific applica- 
tions. The legacy process provided only 
a simple e-mail indicating success of 
transaction, and no further accounting 
of the forward-link transaction. 

The Phase 2 MaROS forward-file 
management functions represent a sig- 
nificant upgrade of this relay system. 
This version provides a lander team the 
capability of selecting a set of “forward- 
link” files to be radiated to an orbiter 
for relay during a chosen communica- 
tions window. These forward-link files 
contain critical flight data such as 
spacecraft command sequences and 
flight software uploads; this new 
MaROS functionality is classified Class 


B software. This new software version 
also includes the capability for lander 
and orbiter team members to associate 
predefined messages to the chosen set 
of forward-link files. Lander teams can 
specify authorizations for the orbiter 
team such as “go for radiation,” and or- 
biter team members may specify status 
messages such as “onboard spacecraft.” 
All of the status data is tracked in a 
database and provided via a shared 
service interface. The system provides a 
high level of accountability into the for- 
ward-link process. 

This work was done by Daniel A. Allard, 
Michael N. Wallick, Franklin FI. Fly, and Roy 
E. Gladden of Caltech for NASA’s Jet Propul- 
sion Laboratory. Further information is con- 
tained in a TSP (see page 1 ). 

This software is available for commercial li- 
censing. Please contact Dan Broderick at 
daniel.f.brodmck@jpl. nasa.gov. Refer to NPO- 
47942. 


@ Two Mechanisms to Avoid 
Control Conflicts Resulting 
from Uncoordinated Intent 

This software implements a real-time 
access control protocol that is intended 
to make all connected users aware of the 
presence of other connected users, and 
which of them is currently in control of 
the system. Here, “in control” means 
that a single user is authorized and en- 
abled to issue instructions to the system. 

The software also implements a goal 
scheduling mechanism that can detect 
situations where plans for the operation 
of a target system proposed by different 
users overlap and interact in conflicting 
ways. In such situations, the system can 
either simply report the conflict (reject- 
ing one goal or the entire plan), or 
reschedule the goals in a way that does 
not conflict. 

The access control mechanism (and 
associated control protocol) is unique. 
Other access control mechanisms are 
generally intended to authenticate users, 
or exclude unauthorized access. This 
software does neither, and would likely 
depend on having some other mecha- 
nism to support those requirements. 

This work was done by Andrew H. 
Mishkin, Daniel L. Dvorak, David A. Wag- 
ner, and Matthew B. Bennett of Caltech for 
NASA’s Jet Propulsion Laboratory. Further in- 
formation is contained in a TSP (see page 1 ). 
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